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ABSTRACT 

The Space Flyer Unit (SFU) is an 
unmanned, multi-purpose, retrievable and 
reusable space platform. The first mission 
of SFU (SFU-1) will be launched by 
NASDA’s H-II launch vehicle in early 
1995, and retrieved by NASA’s Space 
Shuttle after several months in orbit. Two 
Japanese ground stations, several ground 
stations of NASA, and a ground station in 
Chile are used for tracking of SFU-1. The 
control center of SFU-1 is the Sagamihara 
Operations Center (SOC) of ISAS located in 
Sagamihara, Japan. This paper describes 
the tracking and data acquisition network 
for SFU-1, the configuration and design 
policy of the SFU operations control 
system, and data processing schemes used 
for mission operations of SFU. 

Key Words: Mission operations, spacecraft 
tracking system, space data system 

1. INTRODUCTION 

The Space Flyer Unit (SFU) is an 
unmanned, multi-purpose, retrievable and 
reusable space platform (Ref. 1). SFU is 
jointly developed by the following three 
institutes of the Japanese government : (1) 
the Institute of Space and Astronautical 
Science (ISAS) under the Ministry of 
Education, (2) the Institute for Unmanned 
Space Experiment Free Flyer (USEF) under 
the Ministry of International Trade and 
Industry, and (3) the National Space 
Development Agency of Japan (NASDA) 
under the Science and Technology Agency. 

The SFU spacecraft consists of the core 
system and payloads (experiment 
equipments). The core system provides the 
payloads with standardized services such as 
electric power, command and data 
handling, etc. The core system of SFU is 
reusable if approriate refurbishment and 
maintenance are performed after the flight. 
Therefore, SFU can make several flights 


without major modifications to the core 
system, each time with a different set of 
payloads. Each payload is independently 
operated provided its operations do not 
cause resource conflicts with other 
payloads. 

The first mission of SFU (SFU-1) will be 
launched by NASDA’s H-II launch vehicle 
from Tanegashima Space Center in Japan 
in early 1995, and retrieved by NASA’s 
Space Shuttle after several months in orbit. 
The operational altitude is about 500km, 
while the retrieval will take place at about 
300km. SFU-1 has the following eleven 
payloads : 

- Two-dimensional array deployment 

- High voltage solar array experiment 

- Infrared telescope 

- Electric propulsion experiment 

- Material experiment 

- Space biology experiment 

- Space plasma measurement 

- Gradient heating furnace 

- Mirror heating furnace 

- Isothermal heating furnace 

- Testing of the exposed facility of the 
Japanese module of the Space Station 
Freedom 

The following sections describe the tracking 
and data acquisition network for SFU-1, 
the configuration and design policy of the 
SFU operations control system, and data 
processing schemes used for mission 
operations of SFU. 

2. TRACKING AND DATA ACQUISITION 
NETWORK FOR SFU 

The ground stations to be used for a 
particular flight of SFU are selected based 
on the operational requirements of that 
flight, and the location of the control 
center is also decided based on the 
responsibility assignment of that flight. 
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Fig. 1 shows the tracking and data 
acquisition network for the first flight of 
SFU (SFU-1). The primary ground station 
for SFU-1 is the Kagoshima Space Center 
(KSC) of ISAS located in the southern part 
of Japan. The Okinawa Tracking and Data 
Acquisition Station (OTDS) of NASDA, 
located in an island i nr the southern part of 
Japan, is used as a backup ground station 
to ISAS KSC during critical phases. 

Since the operational altitude of SFU-1 is 
about 500km, contact with those Japanese 
stations can be established only during five 
or six orbits out of 16 orbits per day. 
Therefore, three Deep Space Network 
(DSN) stations of NASA (i.e. Goldstone, 
Canberra and Madrid) and three Ground 
Spacecraft Tracking and Data Network 
(GSTDN) stations of NASA (i.e. Bermuda, 
Wallops and Merritt Island) are used to 
extend the ground coverage during critical 
phases. The Santiago ground station of the 
University of Chile is also used during 
critical phases. Since the Santiago station 
covers almost the same orbits as the 
Japanese stations augmenting the coverage 
from the Japanese stations, the Santiago 
station serves as an ideal auxiliary station 
when critical operations are performed over 
the Japanese stations. 


The control center of SFU-1 is the 
Sagamihara Operations Center (SOC) of 
ISAS, which is in the city of Sagamihara 
of Japan. All flight operations for SFU-1 
are performed at SOC except for the 
proximity operarions phase during which 
SFU communicates directly with the Space 
Shuttle Orbiter. 

Except for the proximity operations phase, 
all commands are generated at SOC and 
transmitted to SFU through a ground 
station in realtime. Realtime telemetry 
data received at a ground station is 
transferred to SOC in realtime, where it is 
monitored, analyzed and archived. Playback 
data from the onboard data recorder is 
temporarily stored at the receiving ground 
station and delivered to SOC in an offline 
mode after the tracking pass. 

Orbit determination is performed at SOC 
and the Jet Propulsion Laboratory (JPL) of 
NASA during critical phases. During the 
mission operations phase, orbit 
determination is performed at the Tracking 
and Control Center (TACC) of NASDA 
based on the RARR data from ISAS KSC. 
During the rendezvous operations before 
the retrieval, C-band radar stations of the 
U.S. Government are used for orbit 
determination of SFU, and the Johnson 
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Space center (JSC) of NASA provides SOC 
with the state vectors of SFU. 

During the proximity operations phase, 
telemetry data is monitored at the Space 
Shuttle Orbiter, the Mission Control Center 
(MCC) of JSC and SOC. Commands will 
probably be issued at the Space Shuttle 
Orbiter and MCC of JSC during this phase. 

3. SFU OPERATIONS CONTROL SYSTEM 

3.1 Design Philosophy 

The SFU operations control system is 
dedicated to SFU, not shared with other 
projects, because the mission operations 
requirements for SFU are very different 
from those of other Japanese space 
missions. The following is the design 
philosophy of the SFU operations control 
system: 

1) Virtually any ground station can be 
incorporated into the system with only a 
small modification to the gateway 
software. The control center can be 
placed at any of the three institutes 
participating in the SFU project, 

2) A distributed system architecture and a 
modularized software structure are 
adopted so that the system can be 
modified easily for future flights of SFU 
and new technology can be introduced 
without modifying the entire system. 

3) Industry standard software and 
communications protocols are used 
whenever possible in order to facilitate 
interconnection of computers of different 
manufacturers. 

3.2 System Configuration 

Fig. 2 shows the basic configuration of the 
operations control system for SFU-1. There 
are some other offline computers which are 
not shown in Fig. 2. All the computers at 
SOC use the UNIX operating system, and 
most of the software developed for this 
system is implemented in the C 
programming language. 

There are two major local area networks 
(LAN’s) at SOC, which are shown as two 
thick lines in Fig, 2. These are standard 


Ethernets, and TCP/IP is used as the 
communications protocol. The left LAN 
(SFU LAN) is basically for online 
spacecraft operations, while the right LAN 
(SFU Experiment LAN) is used for 
distributing data to experiment data 
processing computers. 

The SFU Gateway is a communications 
processor used to communicate with ground 
stations and other space centers such as 
JPL and JSC. The SFU Gateway receives 
telemetry data, orbit data (state vectors 
and RARR data) and administrative data 
(sequence of events, etc.) from a ground 
station or another space center, and 
transfers the received data to an 
appropriate computer at SOC with the SFU 
standard protocol and format. The SFU 
Gateway receives command data, orbit data 
and administrative data from a computer 
at SOC, and transfers the received data to 
an appropriate ground station or center. 
The SFU Gateway also stores the received 
data temporarily in case the data is lost 
during transmission. The SFU gateway 
consists of a primary computer and a 
backup computer. 

The SFU Monitor and Control Computer 
(SMCC) is used to issue commands and to 
monitor and archive housekeeping 
telemetry data. SMCC consists of a 
primary host computer, a backup host 
computer and several workstations for 
man/machine interface. These workstations 
are connected to one of the host computers 
via a LAN local to SMCC. 

The Timeline Generator (TLG) validates 
planned operations sequences and generates 
command sequences. TLG consists of a 
primary workstation and a backup 
workstation. 

The Experiment Monitor Computer (EMC) 
is used to monitor and archive experiment 
and housekeeping telemetry data. It 
distributes telemetry data with some 
ancillary data to the Experiment Data 
Processing computers where offline analysis 
of experiment data is performed. EMC 
consists of a host computer and several 
workstations for man/machine interface. 
These workstations are connected to the 
host computer via a LAN local to EMC. 
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Fig. 2 SFU-1 Operations Control System 


The Orbit Data Processing Computer 
(ODPC) performs orbit propagation and 
coordinate system conversion. ODPC 
consists of one workstation. 

The SFU System Simulator (SSS) receives 
commands from SMCC, simulates some of 
the subsystems and experiments of SFU, 
and sends telemetry to SMCC and EMC. 
SSS consists of two host compouters 
(primary and backup) and two workstations 
(primary and backup). 

The experimenters can bring any 
computers as Experiment Data Procesing 
Computers (EDPC’s) if they can be 
connected to the SFU Experiment LAN. 
For the first flight, several minicomputers 
and several workstations will be used as 
EDPC’s. There is no connection to other 
computer networks such as Internet 
because of security requirements. 

4. COMMAND DATA PROCESSING 

4.1 Mission Planning and Command 
Generation 

Mission planning is carried out by 
integrating into the mission timeline the 
Functional Objectives (FO’s) requested by 
the experimenters and flight planning 


team. An FO is a unit for generating the 
mission timeline. Each FO has a sequence 
of commands to be executed, the amount of 
resources required to perform the FO, and 
FO execution rules related to that FO (e.g. 
FO’s which must be executed prior to that 
FO). There is a standard format to describe 
FO’s and each FO is generated as an FO 
file by some offline computer. The 
command sequence in the FO file is 
written in a high level language called the 
SFU Command Language (SCL). Some FO 
files (e.g., FO’s for orbit correction 
maneuvers) are automatically generated by 
an offline computer. 

The requested FO’s are arranged by an 
operator, and a time ordered FO sequence 
is fed to the Timeline Generator (TLG). 
TLG checks whether or not the FO 
sequence violates resource allocation rules 
or FO execution rules. If the sequence 
violates any of the rules, an operater 
modifies the FO sequence through 
interctive operations with TLG. When this 
process is completed and the final FO 
sequence is obtained, TLG generates an 
Event File which contains the integrated 
sequence of commands generated from the 
original FO files. TLG also calculates event 
times such as AOS and LOS times, and 
includes the event information in the 
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Event File. The entire Event File is 
written in SCL. 

4.2 Command Execution and Verification 

The Event File generated by TLG is sent 
to SMCC (Fig. 3). The Event File is then 
interpreted and executed in the following 
way. Commands to be executed during a 
station contact are converted to binary 
command data and transmitted to the 
spacecraft with some interactive operations 
by the operator. Commands to be loaded in 
the onboard command memory and 
executed later are converted to memory 
load commands and transmitted to the 
spacecraft by the directions of the operator. 
Commands in the Event File are 
automatically transmitted unless other 
operations are specified in the Event File. 
The operator can abort the execution of the 
Event File and manually issue commands 
any time. 

If the spacecraft must be in a certain 
status when a command is going to be 
executed, then SMCC verifies the status of 
the spacecraft using the received telemetry 
data before sending the command. After 
sending a command, the result of the 



Fig. 3 Command Data Flow 


command execution is verified with the 
telemetry data. When a critical command 
has been sent, the command transmission 
process is suspended until the execution 
result is verified. For a non-critical 
command, the execution result is not 
verified right after the transmission. At the 
time specified in the Event File, the 
execution results of non-critical commands 
which have not been verified are verified 
simultaneously. If a verification fails, 
SMCC generates an anomaly report, alarm 
the operator, and abort the execution of the 
Event File. 

5. TELEMETRY DATA PROCESSING 

5.1 Telemetry Checking 

Received telemetry data is fed to SMCC 
and EMC simultaneously (Fig. 4). SMCC 
processes only housekeeping data, while 
EMC can process both housekeeping and 
experiment data. Against received 
telemetry data, two kinds of checking are 
performed as follows: 


1) Limit checking - Checking that the 
value of a received telemetry data is 
between a pair of fixed limit values. 



Fig. 4 Telemetry Data Flow 
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This checking is performed to detect a 
hardware error. Limit checking is 
performed against all realtime telemetry 
at the time of reception. The limit 
values can be changed by changing limit 
data files. 

2) Mode checking - Checking that the value 
or status of a set of received 
housekeeping telemetry data satisfies the 
conditions described in a specified mode 
check file. This checking is performed to 
check that the spacecraft is actually in 
the desired mode. SMCC automatically 
executes mode checking if it is described 
in the Event File. The operator can 
manually initiate mode checking any 
time. Mode checking can also be 
performed in a batch mode against the 
telemetry data of a specified time 
archived in SMCC. Batch mode checking 
is useful for verifying the mode 
transitions of the spacecraft during an 
out-of-contact period. 

If a check fails, an anomaly report is 
generated and the operator is alarmed to 
take an action. 

5.2 Telemetry Display 

Realtime telemetry data is monitored in 
realtime on the workstations of SMCC and 
EMC. Archived data is also displayed with 
the directions of the operator on these 
workstations. The display format is defined 
with a window definition language called 
the Display Format Descriptor (DFD). 
SMCC and EMC reads the display format 
request defined with DFD from a file, and 
generates the display. 

Several windows can be drawn on one 
workstation, and a window consists of a 
alphanumeric table or a graphical plot. 
Some of the windows can be placed on the 
screen as icons, which can be opened with 
a direction of the operator. The display 
format request contains the following 
information for each window: the data 
items to be displayed in the window, the 
format of the table or plot, the colors to be 
used for normal data and out-of-limit data, 


etc. The result of some arithmetic 
operations can also be displayed by 
defining the operations with DFD. If a data 
fails the limit check, the color of the data 
on the display changes. If the data is being 
displayed in one of the icons, the color of 
the icon changes. 

5.3 Telemetry Distribution 

SMCC can provide a text file called the 
SFU Parameter File which contains the 
value of all housekeeping telemetry items 
derived from one major frame of telemetry. 
This file is used by TLG and SSS as the 
initial condition of timeline generation or 
simulation. EMC provides EDPC with the 
set of telemetry data requested by an 
experimenter in the SFDU format. 

6. CONCLUSIONS 

This paper described the tracking and data 
acquisition network and the operations 
control system of SFU-1. The operations 
control system is now in the stage of 
integration testing which will be finished 
in the fall of 1993. 
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